I'm not sure what point this is when they're all hard-coded to the same value? If this is part of a larger series to do dynamic XLEN then sure, but that is a quite large undertaking.

I'm not sure what point this is when they're all hard-coded to the same value?

Agree, It's really of no use if you can make sure of it. The biggest use maybe to reassure beginners who don’t know much about model.

If this is part of a larger series to do dynamic XLEN then sure, but that is a quite large undertaking.

Not yet. But I discussed the issue of dynamic xlen with some people, about usage scenarios and requirements. Here are some conclusions:

• Dynamic XLEN is mainly used for compatibility, such as having RV64 run RV32 programs.
• One of implementation difficulty is that the rv32 rv64 shift instructions are conflicting from dec
• The released K230 chip supports modifying sstatus.uxl, and the mainline kernel also supports it.
• Technical issues outweigh requirements

Personally, I would do a little research on how to implement this in the model

I have thought quite a bit about dynamic XLEN, and the biggest problem is the CSRs that change width.

Essentially what happens is as soon as you change the appropriate bits to change UXLEN or SXLEN, then any UXLEN or SXLEN register gets width-modulated down (or up) to the new size, according to the CSR width modulation algorithm in the spec, and what this means is a field specified in a register at UXLEN - N really does 'move' in some sense when UXLEN changes. The width-modulation algorithm (at least as I read it) is destructive and appears to allow producing illegal values in registers, so presumably some magic needs to happen to ensure that the width-modulated register remains legal.

Other architectures do the sensible thing of saying registers are exactly 64-bits and then defining the 32-bit view of the register when executing 32-bit code, or providing two registers for the lower and upper 32-bits (RISC-V does this for some registers).

There are also some CSRs that are defined as current XLEN-width, so presumably they need to be width-modulated every time you change modes that have a different XLEN?